home *** CD-ROM | disk | FTP | other *** search
/ Aminet 1 / Aminet - June 1993 [Walnut Creek].iso / usenet / sources / volume90 / unix / uucp103d / part15 < prev    next >
Encoding:
Internet Message Format  |  1990-02-04  |  50.7 KB

  1. Path: xanth!cs.odu.edu!Amiga-Request
  2. From: Amiga-Request@cs.odu.edu (Amiga Sources/Binaries Moderator)
  3. Newsgroups: comp.sources.amiga
  4. Subject: v90i059: uucp 1.03D - unix compatible uucp/mail/news system, Part15/16
  5. Message-ID: <11298@xanth.cs.odu.edu>
  6. Date: 4 Feb 90 02:43:55 GMT
  7. Sender: tadguy@cs.odu.edu
  8. Reply-To: overload!dillon (Matt Dillon)
  9. Lines: 1350
  10. Approved: tadguy@cs.odu.edu (Tad Guy)
  11. X-Mail-Submissions-To: Amiga@cs.odu.edu
  12.  
  13. Submitted-by: overload!dillon (Matt Dillon)
  14. Posting-number: Volume 90, Issue 059
  15. Archive-name: unix/uucp-1.03d/part15
  16.  
  17. #!/bin/sh
  18. # This is a shell archive.  Remove anything before this line, then unpack
  19. # it by saving it into a file and typing "sh file".  To overwrite existing
  20. # files, type "sh file -c".  You can also feed this as standard input via
  21. # unshar, or by typing "sh <file", e.g..  If this archive is complete, you
  22. # will see the following message at the end:
  23. #        "End of archive 15 (of 16)."
  24. # Contents:  man/Standards.aa
  25. # Wrapped by tadguy@xanth on Sat Feb  3 20:51:25 1990
  26. PATH=/bin:/usr/bin:/usr/ucb ; export PATH
  27. if test -f 'man/Standards.aa' -a "${1}" != "-c" ; then 
  28.   echo shar: Will not clobber existing file \"'man/Standards.aa'\"
  29. else
  30. echo shar: Extracting \"'man/Standards.aa'\" \(48305 characters\)
  31. sed "s/^X//" >'man/Standards.aa' <<'END_OF_FILE'
  32. X
  33. X         Standard for Interchange of USENET Messages
  34. X
  35. X                Mark R. Horton
  36. X
  37. X
  38. X
  39. X
  40. X      1.  Introduction
  41.               Introduction
  42.               Introduction
  43.               Introduction
  44. X
  45. X      This document defines the standard format for  interchange
  46. X      of Network News articles among USENET sites.    It describes
  47. X      the format for  articles  themselves,  and  gives  partial
  48. X      standards for transmission of news.  The news transmission
  49. X      is not entirely standardized in order to give a good    deal
  50. X      of   flexibility   to   the  individual  hosts  to  choose
  51. X      transmission hardware and software, whether to batch news,
  52. X      and so on.
  53. X
  54. X      There are five sections to  this  document.    Section  two
  55. X      section  defines  the  format.   Section three defines the
  56. X      valid control messages.  Section four specifies some valid
  57. X      transmission    methods.  Section five describes the overall
  58. X      news propagation algorithm.
  59. X
  60. X
  61. X      2.  Article Format
  62.               Article Format
  63.               Article Format
  64.               Article Format
  65. X
  66. X      The primary consideration in choosing an article format is
  67. X      that    it  fit  in with existing tools as well as possible.
  68. X      Existing tools include both implementations  of  mail  and
  69. X      news.   (The  notesfiles  system  from  the  University of
  70.                         __________
  71. X      Illinois is considered a news implementation.) A  standard
  72. X      format for mail messages has existed for many years on the
  73. X      ARPANET, and this  format  meets  most  of  the  needs  of
  74. X      USENET.    Since   the   ARPANET   format  is  extensible,
  75. X      extensions to meet the  additional  needs  of  USENET  are
  76. X      easily  made    within the ARPANET standard.  Therefore, the
  77. X      rule is adopted that all  USENET  news  articles  must  be
  78. X      formatted as valid ARPANET mail messages, according to the
  79. X      ARPANET  standard  RFC  822.     This    standard   is    more
  80. X      restrictive  than the ARPANET standard, placing additional
  81. X      requirements on each article and forbidding use of certain
  82. X      ARPANET  features.   However, it should always be possible
  83. X      to use a tool expecting an ARPANET message  to  process  a
  84. X      news    article.   In  any  situation  where  this  standard
  85. X      conflicts with the ARPANET standard,    RFC  822  should  be
  86. X      considered correct and this standard in error.
  87. X
  88. X      An example message is included to illustrate the fields.
  89. X
  90. X
  91. X
  92. X
  93. X
  94. X
  95. X
  96. X
  97. X
  98. X
  99. X
  100. X
  101. X
  102. X
  103. X
  104. X
  105. X
  106. X                    - 2 -
  107. X
  108. X
  109. X
  110. X           Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
  111. X           Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
  112. X           Path: cbosgd!mhuxj!mhuxt!eagle!jerry
  113. X           From: jerry@eagle.uucp (Jerry Schwarz)
  114. X           Newsgroups: net.general
  115. X           Subject: Usenet Etiquette -- Please Read
  116. X           Message-ID: <642@eagle.UUCP>
  117. X           Date: Friday, 19-Nov-82 16:14:55 EST
  118. X           Followup-To: net.news
  119. X           Expires: Saturday, 1-Jan-83 00:00:00 EST
  120. X           Date-Received: Friday, 19-Nov-82 16:59:30 EST
  121. X           Organization: Bell Labs, Murray Hill
  122. X
  123. X           The body of the article comes here, after a blank line.
  124. X
  125. X      Here is an example of a message in the old format  (before
  126. X      the  existence  of this standard).  It is recommended that
  127. X      implementations also accept articles    in  this  format  to
  128. X      ease upward conversion.
  129. X
  130. X           From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
  131. X           Newsgroups: net.general
  132. X           Title: Usenet Etiquette -- Please Read
  133. X           Article-I.D.: eagle.642
  134. X           Posted: Fri Nov 19 16:14:55 1982
  135. X           Received: Fri Nov 19 16:59:30 1982
  136. X           Expires: Mon Jan  1 00:00:00 1990
  137. X
  138. X           The body of the article comes here, after a blank line.
  139. X
  140. X      Some news systems transmit news in the ``A'' format, which
  141. X      looks like this:
  142. X
  143. X           Aeagle.642
  144. X           net.general
  145. X           cbosgd!mhuxj!mhuxt!eagle!jerry
  146. X           Fri Nov 19 16:14:55 1982
  147. X           Usenet Etiquette - Please Read
  148. X           The body of the article comes here, with no blank line.
  149. X
  150. X      An article consists of several header lines, followed by a
  151. X      blank  line,    followed  by  the  body of the message.  The
  152. X      header lines consist of a keyword, a colon, a  blank,  and
  153. X      some    additional  information.   This  is  a subset of the
  154. X      ARPANET standard, simplified to allow simpler software  to
  155. X      handle  it.    The  ``from''  line may optionally include a
  156. X      full name, in the format above, or use the  ARPANET  angle
  157. X      bracket syntax.  To keep the implementations simple, other
  158. X      formats (for example, with part  of  the  machine  address
  159. X      after the close parenthesis) are not allowed.  The ARPANET
  160. X      convention of continuation header lines (beginning with  a
  161. X
  162. X
  163. X
  164. X
  165. X
  166. X
  167. X
  168. X
  169. X
  170. X
  171. X
  172. X                    - 3 -
  173. X
  174. X
  175. X
  176. X      blank or tab) is allowed.
  177. X
  178. X      Certain  headers  are  required,   certain   headers     are
  179. X      optional.   Any unrecognized headers are allowed, and will
  180. X      be passed through unchanged.     The  required    headers  are
  181. X      Relay-Version,  Posting-Version,  From,  Date, Newsgroups,
  182. X      Subject,  Message-ID,  Path.     The  optional    headers  are
  183. X      Followup-To,    Date-Received,    Expires,  Reply-To,  Sender,
  184. X      References, Control, Distribution, Organization.
  185. X
  186. X      2.1  Required Headers
  187.                Required Headers
  188.                Required Headers
  189.                Required Headers
  190. X
  191. X      2.1.1  Relay-Version    This header line shows    the  version
  192.                  _____________
  193. X      of  the  program  responsible for the transmission of this
  194. X      article over the immediate link, that is, the program that
  195. X      is  relaying the article from the next site.    For example,
  196. X      suppose site A sends an article to  site  B,    and  site  B
  197. X      forwards  the  article  to  site  C.     The  message  being
  198. X      transmitted from A to B would have a Relay-Version  header
  199. X      identifying  the  program  running  on  A, and the message
  200. X      transmitted from B to C would identify the program running
  201. X      on  B.  This header can be used to interpret older headers
  202. X      in an upward compatible way.    Relay-Version must always be
  203. X      the  first  in  a message; thus, all articles meeting this
  204. X      standard will begin with an upper case  ``R''.   No  other
  205. X      restrictions are placed on the order of header lines.
  206. X
  207. X      The line contains two  fields,  separated  by  semicolons.
  208. X      The fields are the version and the full domain name of the
  209. X      site.  The version should identify the system program used
  210. X      (e.g.,  ``B'')  as  well  as  a version number and version
  211. X      date.  For example, the header line might contain
  212. X
  213. X           Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
  214. X
  215. X      This header should not be passed on to  additional  sites.
  216. X      A  relay  program,  when  passing  an  article  on, should
  217. X      include only its own Relay-Version, not the  Relay-Version
  218. X      of  some other site.    (For upward compatibility with older
  219. X      software, if a Relay-Version is found in a header which is
  220. X      not the first line, it should be assumed to be moved by an
  221. X      older version of news and deleted.)
  222. X
  223. X      2.1.2  Posting-Version    This   header   identifies     the
  224.                  _______________
  225. X      software  responsible  for  entering this message into the
  226. X      network.  It has the same  format  as  Relay-Version.   It
  227. X      will    normally  identify  the same site as the Message-ID,
  228. X      unless the posting site is serving  as  a  gateway  for  a
  229. X      message  that  already  contains a message ID generated by
  230. X      mail.  (While it is permissible for a gateway  to  use  an
  231. X      externally  generated message ID, the message ID should be
  232. X
  233. X
  234. X
  235. X
  236. X
  237. X
  238. X
  239. X
  240. X
  241. X
  242. X
  243. X                    - 4 -
  244. X
  245. X
  246. X
  247. X      checked to ensure it conforms to this standard and to  RFC
  248. X      822.)
  249. X
  250. X      2.1.3  From  The From line contains the electronic mailing
  251.                  ____
  252. X      address  of  the  person who sent the message, in the ARPA
  253. X      internet syntax.  It may optionally also contain the    full
  254. X      name    of  the person, in parentheses, after the electronic
  255. X      address.  The electronic address is the same as the entity
  256. X      responsible for originating the article, unless the Sender
  257. X      header is present, in which case the From header might not
  258. X      be  verified.   Note    that  in  all site and domain names,
  259. X      upper  and  lower  case  are    considered  the  same,    thus
  260. X      mark@cbosgd.UUCP,  mark@cbosgd.uucp,    and mark@CBosgD.UUcp
  261. X      are all equivalent.  User names may or  may  not  be    case
  262. X      sensitive,   for   example,    Billy@cbosgd.UUCP  might  be
  263. X      different from BillY@cbosgd.UUCP.  Programs  should  avoid
  264. X      changing  the case of electronic addresses when forwarding
  265. X      news or mail.
  266. X
  267. X      RFC 822 specifies that all text in parentheses  is  to  be
  268. X      interpreted as a comment.  It is common in ARPANET mail to
  269. X      place the full name of the user in a comment at the end of
  270. X      the  From  line.   This  standard  specifies    a more rigid
  271. X      syntax.  The full name is not considered a comment, but an
  272. X      optional part of the header line.  Either the full name is
  273. X      omitted, or it appears in parentheses after the electronic
  274. X      address  of  the person posting the article, or it appears
  275. X      before an electronic address enclosed in  angle  brackets.
  276. X      Thus, the three permissible forms are:
  277. X
  278. X           From: mark@cbosgd.UUCP
  279. X           From: mark@cbosgd.UUCP (Mark Horton)
  280. X           From: Mark Horton <mark@cbosgd.UUCP>
  281. X
  282. X      Full names may contain any printing ASCII characters    from
  283. X      space through tilde, with the exceptions that they may not
  284. X      contain parentheses ``(''  or  ``)'',  or  angle  brackets
  285. X      ``<''  or ``>''.  Additional restrictions may be placed on
  286. X      full names  by  the  mail  standard,    in  particular,  the
  287. X      characters  comma  ``,'', colon ``:'', and semicolon ``;''
  288. X      are inadvisable in full names.
  289. X
  290. X      2.1.4  Date  The Date line (formerly  ``Posted'')  is  the
  291.                  ____
  292. X      date,  in  a    format    that  must be acceptable both to the
  293. X      ARPANET and to the getdate routine, that the    article  was
  294. X      originally  posted  to  the  network.   This    date remains
  295. X      unchanged as the  article  is  propagated  throughout  the
  296. X      network.  One format that is acceptable to both is
  297. X
  298. X           Weekday, DD-Mon-YY HH:MM:SS TIMEZONE
  299. X
  300. X
  301. X
  302. X
  303. X
  304. X
  305. X
  306. X
  307. X
  308. X
  309. X
  310. X
  311. X                    - 5 -
  312. X
  313. X
  314. X
  315. X      Several examples of  valid  dates  appear  in  the  sample
  316. X      article above.  Note in particular that ctime format:
  317. X
  318. X           Wdy Mon DD HH:MM:SS YYYY
  319. X
  320. X      is not acceptable because it is not a valid ARPANET  date.
  321.              ___
  322. X      However, since older software still generates this format,
  323. X      news implementations are encouraged to accept this  format
  324. X      and translate it into an acceptable format.
  325. X
  326. X      The contents of the TIMEZONE field is currently subject to
  327. X      revision.   Eventually,  we  hope  to  accept all possible
  328. X      worldwide time zone  abbreviations,  including  the  usual
  329. X      American  zones  (PST, PDT, MST, MDT, CST, CDT, EST, EDT),
  330. X      the    other    North    American   zones   (Bering   through
  331. X      Newfoundland),  European  zones,  Australian zones, and so
  332. X      on.  Lacking a complete list at present (and unsure if  an
  333. X      unambiguous    list   exists),   authors  of  software  are
  334. X      encouraged to keep this code flexible, and  in  particular
  335. X      not  to  assume  that  time  zone  names are exactly three
  336. X      letters long.   Implementations  are    free  to  edit    this
  337. X      field,  keeping  the    time the same, but changing the time
  338. X      zone (with an appropriate adjustment  to  the  local  time
  339. X      shown) to a known time zone.
  340. X
  341. X      2.1.5  Newsgroups  The  Newsgroups  line  specifies  which
  342.                  __________
  343. X      newsgroup  or newsgroups the article belongs in.  Multiple
  344. X      newsgroups  may  be  specified,  separated  by  a   comma.
  345. X      Newsgroups  specified  must  all  be the names of existing
  346. X      newsgroups, as no new newsgroups will be created by simply
  347. X      posting to them.
  348. X
  349. X      Wildcards (e.g., the word ``all'') are never allowed in  a
  350. X      Newsgroups  line.  For example, a newsgroup ``net.all'' is
  351. X      illegal, although a newsgroup name  ``net.sport.football''
  352. X      is permitted.
  353. X
  354. X      If an article is received with a Newsgroups  line  listing
  355. X      some    valid newsgroups and some invalid newsgroups, a site
  356. X      should  not  remove  invalid    newsgroups  from  the  list.
  357. X      Instead,  the  invalid  newsgroups should be ignored.  For
  358. X      example,  suppose  site  A  subscribes  to   the   classes
  359. X      ``btl.all''  and  ``net.all'', and exchanges news articles
  360. X      with site B,    which  subscribes  to  ``net.all''  but  not
  361. X      ``btl.all''.    Suppose   A   receives   an  article  with
  362. X      ``Newsgroups: net.micro,btl.general''.   This  article  is
  363. X      passed  on  to  B because B receives net.micro, but B does
  364. X      not receive btl.general.  A must leave the Newsgroup    line
  365. X      unchanged.   If  it  were  to  remove ``btl.general'', the
  366. X      edited header could  eventually  reenter  the  ``btl.all''
  367. X      class,  resulting in an article that is not shown to users
  368. X
  369. X
  370. X
  371. X
  372. X
  373. X
  374. X
  375. X
  376. X
  377. X
  378. X
  379. X                    - 6 -
  380. X
  381. X
  382. X
  383. X      subscribing  to  ``btl.general''.   Also,  followups  from
  384. X      outside ``btl.all'' would not be shown to such users.
  385. X
  386. X      2.1.6  Subject   The    Subject  line  (formerly  ``Title'')
  387.                  _______
  388. X      tells  what the article is about.  It should be suggestive
  389. X      enough of the contents of the article to enable  a  reader
  390. X      to  make  a  decision whether to read the article based on
  391. X      the  subject    alone.     If  the  article  is  submitted  in
  392. X      response  to another article (e.g., is a ``followup'') the
  393. X      default subject should  begin  with  the  four  characters
  394. X      ``Re:  ''  and the References line is required.  (The user
  395. X      might wish to edit the subject of the  followup,  but  the
  396. X      default should begin with ``Re: ''.)
  397. X
  398. X      2.1.7  Message-ID  The Message-ID line gives the article a
  399.                  __________
  400. X      unique  identifier.  The same message ID may not be reused
  401. X      during the lifetime of any article with the  same  message
  402. X      ID.    (It  is recommended that no message ID be reused for
  403. X      at least two years.) Message ID's have the syntax
  404. X
  405. X           "<" "string not containing blank or >" ">"
  406. X
  407. X      In order to conform to RFC 822, the Message-ID  must    have
  408. X      the format
  409. X
  410. X           "<" "unique" "@" "full domain name" ">"
  411. X
  412. X      where ``full domain name'' is the full name of the host at
  413. X      which  the article entered the network, including a domain
  414. X      that host is in, and unique  is  any    string    of  printing
  415. X      ASCII  characters,  not  including  "<", ">", or "@".  For
  416. X      example,  the  "unique"   part   could   be   an   integer
  417. X      representing    a  sequence number for articles submitted to
  418. X      the network, or a short string derived from the  date  and
  419. X      time    the article was created.  For example, valid message
  420. X      ID for an article submitted from  site  ucbvax  in  domain
  421. X      Berkeley.ARPA   would   be  "<4123@ucbvax.Berkeley.ARPA>".
  422. X      Programmers are urged not to make  assumptions  about  the
  423. X      content  of  message    ID  fields  from other hosts, but to
  424. X      treat them as unknown character strings.  It is not  safe,
  425. X      for  example, to assume that a message ID will be under 14
  426. X      characters,  nor  that  it  is  unique  in  the  first  14
  427. X      characters.
  428. X
  429. X      The angle brackets are considered part of the message  ID.
  430. X      Thus,  in  references  to  the  message  ID,    such  as the
  431. X      ihave/sendme    and  cancel  control  messages,  the   angle
  432. X      brackets  are  included.   White  space  characters (e.g.,
  433. X      blank and tab) are not  allowed  in  a  message  ID.     All
  434. X      characters  between  the  angle  brackets must be printing
  435. X      ASCII characters.
  436. X
  437. X
  438. X
  439. X
  440. X
  441. X
  442. X
  443. X
  444. X
  445. X
  446. X
  447. X                    - 7 -
  448. X
  449. X
  450. X
  451. X      2.1.8  Path  This line shows the path the article took  to
  452.                  ____
  453. X      reach  the  current  system.     When  a system forwards the
  454. X      message, it should add its own name to the list of systems
  455. X      in  the  Path  line.     The  names  may be separated by any
  456. X      punctuation      character    or     characters,    thus
  457. X      ``cbosgd!mhuxj!mhuxt'',   ``cbosgd,  mhuxj,  mhuxt'',  and
  458. X      ``@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp''     and      even
  459. X      ``teklabs,   zehntel,   sri-unix@cca!decvax''   are  valid
  460. X      entries.  (The latter path indicates a message that passed
  461. X      through  decvax,  cca,  sri-unix, zehntel, and teklabs, in
  462. X      that order.) Additional names should    be  added  from  the
  463. X      left,  for  example,    the  most recently added name in the
  464. X      third example was ``teklabs''.  Letters,  digits,  periods
  465. X      and  hyphens    are  considered  part  of  site names; other
  466. X      punctuation, including blanks, are considered separators.
  467. X
  468. X      Normally, the rightmost name    will  be  the  name  of  the
  469. X      originating  system.     However,  it is also permissible to
  470. X      include an extra entry on the right, which is the name  of
  471. X      the  sender.     This is for upward compatibility with older
  472. X      system.
  473. X
  474. X      The Path line is not used for replies, and should  not  be
  475. X      taken  as  a    mailing address.  It is intended to show the
  476. X      route the message  travelled    to  reach  the    local  site.
  477. X      There  are  several  uses for this information.  One is to
  478. X      monitor USENET routing for performance  reasons.   Another
  479. X      is  to  establish  a path to reach new sites.  Perhaps the
  480. X      most important is to cut down on redundant USENET  traffic
  481. X      by failing to forward a message to a site that is known to
  482. X      have already received it.   In  particular,  when  site  A
  483. X      sends  an article to site B, the Path line includes ``A'',
  484. X      so that site B will not immediately send the article    back
  485. X      to  site  A.     The  site  name  each site uses to identify
  486. X      itself should be  the  same  as  the    name  by  which  its
  487. X      neighbors  know  it,    in  order  to make this optimization
  488. X      possible.
  489. X
  490. X      A site adds its own name to the front of a  path  when  it
  491. X      receives  a message from another site.  Thus, if a message
  492. X      with path A!X!Y!Z is passed from site A to site B, B    will
  493. X      add  its own name to the path when it receives the message
  494. X      from A, e.g., B!A!X!Y!Z.  If B then passes the message  on
  495. X      to  C,  the  message    sent  to  C  will  contain  the path
  496. X      B!A!X!Y!Z, and when C receives it, C    will  change  it  to
  497. X      C!B!A!X!Y!Z.
  498. X
  499. X      Special upward compatibility note: Since the From, Sender,
  500. X      and  Reply-To lines are in internet format, and since many
  501. X      USENET  sites  do  not  yet  have   mailers    capable   of
  502. X      understanding  internet  format,  it would break the reply
  503. X
  504. X
  505. X
  506. X
  507. X
  508. X
  509. X
  510. X
  511. X
  512. X
  513. X
  514. X                    - 8 -
  515. X
  516. X
  517. X
  518. X      capability to completely sever the connection between  the
  519. X      Path    header    and  the  reply  function.   Thus, sites are
  520. X      required to continue to keep the Path line  in  a  working
  521. X      reply  format  as much as possible, until January 1, 1984.
  522. X      It is recognized that the path is not always a valid reply
  523. X      string in older implementations, and no requirement to fix
  524. X      this problem is placed on implementations.   However,  the
  525. X      existing  convention of placing the site name and an ``!''
  526. X      at the front of the path, and of starting  the  path    with
  527. X      the  site  name,  an    ``!'',  and the user name, should be
  528. X      maintained at least until 1984.
  529. X
  530. X      2.2  Optional Headers
  531.                Optional Headers
  532.                Optional Headers
  533.                Optional Headers
  534. X
  535. X      2.2.1  Reply-To  This line has the same  format  as  From.
  536.                  ________
  537. X      If present, mailed replies to the author should be sent to
  538. X      the name given here.    Otherwise, replies are mailed to the
  539. X      name    on the From line.  (This does not prevent additional
  540. X      copies from being sent to recipients named by the replier,
  541. X      or  on  To  or  Cc lines.) The full name may be optionally
  542. X      given, in parentheses, as in the From line.
  543. X
  544. X      2.2.2  Sender  This field is present only if the submitter
  545.                  ______
  546. X      manually enters a From line.    It is intended to record the
  547. X      entity responsible  for  submitting  the  article  to  the
  548. X      network,  and  should  be  verified by the software at the
  549. X      submitting site.
  550. X
  551. X      For example, if John Smith is visiting CCA and  wishes  to
  552. X      post    an  article to the network, using friend Sarah Jones
  553. X      account, the message might read
  554. X
  555. X           From: smith@ucbvax.uucp (John Smith)
  556. X           Sender: jones@cca.arpa (Sarah Jones)
  557. X
  558. X      If a gateway    program  enters  a  mail  message  into  the
  559. X      network at site sri-unix, the lines might read
  560. X
  561. X           From: John.Doe@CMU-CS-A.ARPA
  562. X           Sender: network@sri-unix.ARPA
  563. X
  564. X      The primary purpose of this field is to be able  to  track
  565. X      down    articles to determine how they were entered into the
  566. X      network.  The  full  name  may  be  optionally  given,  in
  567. X      parentheses, as in the From line.
  568. X
  569. X      2.2.3  Followup-To  This  line  has  the  same  format  as
  570.                  ___________
  571. X      Newsgroups.    If  present,  follow-up  articles  are to be
  572. X      posted to the newsgroup(s) listed here.  If this  line  is
  573. X      not  present,  followups  are  posted  to the newsgroup(s)
  574. X      listed in the Newsgroups line, except  that  followups  to
  575. X
  576. X
  577. X
  578. X
  579. X
  580. X
  581. X
  582. X
  583. X
  584. X
  585. X
  586. X                    - 9 -
  587. X
  588. X
  589. X
  590. X      ``net.general'' should instead go to ``net.followup''.
  591. X
  592. X      2.2.4  Date-Received    This line (formerly ``Received'') is
  593.                  _____________
  594. X      in  a  legal    USENET date format.  It records the date and
  595. X      time that the article was  first  received  on  the  local
  596. X      system.   If    this  line  is    present  in an article being
  597. X      transmitted from one host to another, the  receiving    host
  598. X      should  ignore  it  and  replace it with the current date.
  599. X      Since this field is intended for local use only,  no    site
  600. X      is  required    to support it.    However, no site should pass
  601. X      this field on to another site unchanged.
  602. X
  603. X      2.2.5  Expires  This line,  if  present,  is    in  a  legal
  604.                  _______
  605. X      USENET  date    format.  It specifies a suggested expiration
  606. X      date for the article.  If not present, the  local  default
  607. X      expiration date is used.
  608. X
  609. X      This field is intended to be used  to  clean    up  articles
  610. X      with    a  limited usefulness, or to keep important articles
  611. X      around for longer than  usual.   For    example,  a  message
  612. X      announcing  an  upcoming  seminar could have an expiration
  613. X      date the day after the seminar, since the message  is  not
  614. X      useful  after the seminar is over.  Since local sites have
  615. X      local  policies  for    expiration  of    news  (depending  on
  616. X      available disk space, for instance), users are discouraged
  617. X      from providing expiration dates for articles unless  there
  618. X      is  a  natural  expiration date associated with the topic.
  619. X      System software should  almost  never  provide  a  default
  620. X      Expires line.  Leave it out and allow local policies to be
  621. X      used unless there is a good reason not to.
  622. X
  623. X      2.2.6  References  This field lists the  message  ID's  of
  624.                  __________
  625. X      any articles prompting the submission of this article.  It
  626. X      is required for all follow-up articles, and forbidden when
  627. X      a new subject is raised.  Implementations should provide a
  628. X      follow-up command, which allows a user to post a follow-up
  629. X      article.   This  command  should  generate  a Subject line
  630. X      which is the same as the original article, except that  if
  631. X      the original subject does not begin with ``Re: '' or ``re:
  632. X      '', the four characters ``Re: '' are inserted  before  the
  633. X      subject.   If  there is no References line on the original
  634. X      header, the References line should contain the message  ID
  635. X      of  the  original  article (including the angle brackets).
  636. X      If the original article does have a References  line,  the
  637. X      followup  article should have a References line containing
  638. X      the text of the original References line, a blank, and the
  639. X      message ID of the original article.
  640. X
  641. X      The purpose of the References header is to allow  articles
  642. X      to  be  grouped  into  conversations by the user interface
  643. X      program.  This allows conversations within a newsgroup  to
  644. X
  645. X
  646. X
  647. X
  648. X
  649. X
  650. X
  651. X
  652. X
  653. X
  654. X
  655. X                    - 10 -
  656. X
  657. X
  658. X
  659. X      be  kept  together,  and  potentially users might shut off
  660. X      entire conversations without unsubscribing to a newsgroup.
  661. X      User    interfaces  may not make use of this header, but all
  662. X      automatically  generated  followups  should  generate  the
  663. X      References line for the benefit of systems that do use it,
  664. X      and manually generated followups (e.g. typed in well after
  665. X      the  original  article  has  been  printed by the machine)
  666. X      should be encouraged to include them as well.
  667. X
  668. X      2.2.7  Control  If an article contains a Control line, the
  669.                  _______
  670. X      article  is  a control message.  Control messages are used
  671. X      for communication among USENET host machines,  not  to  be
  672. X      read    by  users.   Control messages are distributed by the
  673. X      same newsgroup mechanism as ordinary messages.   The    body
  674. X      of the Control header line is the message to the host.
  675. X
  676. X      For  upward  compatibility,  messages   that     match     the
  677. X      newsgroup   pattern    ``all.all.ctl''   should   also   be
  678. X      interpreted as control messages.  If no Control: header is
  679. X      present  on  such  messages,    the  subject  is used as the
  680. X      control message.  However, messages on newsgroups matching
  681. X      this pattern do not conform to this standard.
  682. X
  683. X      2.2.8  Distribution    This  line  is    used  to  alter  the
  684.                  ____________
  685. X      distribution scope of the message.  It has the same format
  686. X      as the Newsgroups  line.   User  subscriptions  are  still
  687. X      controlled  by  Newsgroups, but the message is sent to all
  688. X      systems subscribing to the newsgroups on the    Distribution
  689. X      line instead of the Newsgroups line.    Thus, a car for sale
  690. X      in New Jersey might have headers including
  691. X
  692. X           Newsgroups: net.auto,net.wanted
  693. X           Distribution: nj.all
  694. X
  695. X      so that  it  would  only  go    to  persons  subscribing  to
  696. X      net.auto  or    net.wanted within New Jersey.  The intent of
  697. X      this header is to further restrict the distribution  of  a
  698. X      newsgroup, not to increase it.  A local newsgroup, such as
  699. X      nj.crazy-eddie, will probably not be propagated  by  sites
  700. X      outside  New    Jersey    that do not show such a newsgroup as
  701. X      valid.  Wildcards in newsgroup names in  the    Distribution
  702. X      line are allowed.  Followup articles should default to the
  703. X      same Distribution line as the original  article,  but  the
  704. X      user    can change it to a more limited one, or escalate the
  705. X      distribution if it was originally restricted    and  a    more
  706. X      widely distributed reply is appropriate.
  707. X
  708. X      2.2.9  Organization  The text of  this  line    is  a  short
  709.                  ____________
  710. X      phrase  describing  the  organization  to which the sender
  711. X      belongs, or to which the machine belongs.  The  intent  of
  712. X      this    line  is  to  help  identify  the person posting the
  713. X
  714. X
  715. X
  716. X
  717. X
  718. X
  719. X
  720. X
  721. X
  722. X
  723. X
  724. X                    - 11 -
  725. X
  726. X
  727. X
  728. X      message, since site names are often cryptic enough to make
  729. X      it  hard  to    recognize the organization by the electronic
  730. X      address.
  731. X
  732. X
  733. X      3.  Control Messages
  734.               Control Messages
  735.               Control Messages
  736.               Control Messages
  737. X
  738. X      This section lists the control messages currently defined.
  739. X      The  body  of  the  Control header is the control message.
  740. X      Messages are a sequence of zero or more  words,  separated
  741. X      by  white  space  (blanks or tabs).  The first word is the
  742. X      name    of  the  control  message,   remaining     words     are
  743. X      parameters  to  the  message.  The remainder of the header
  744. X      and the body of the message are also potential parameters;
  745. X      for  example,  the  From  line might suggest an address to
  746. X      which a response is to be mailed.
  747. X
  748. X      Implementors    and  administrators  may  choose  to   allow
  749. X      control  messages  to  be automatically carried out, or to
  750. X      queue  them  for  manual  processing.   However,  manually
  751. X      processed messages should be dealt with promptly.
  752. X
  753. X      3.1  Cancel
  754.                Cancel
  755.                Cancel
  756.                Cancel
  757. X
  758. X           cancel <message ID>
  759. X
  760. X      If an article with the given message ID is present on  the
  761. X      local  system,  the  article is cancelled.  This mechanism
  762. X      allows a user to cancel an article after the    article  has
  763. X      been distributed over the network.
  764. X
  765. X      Only the author of the article or the local super user  is
  766. X      allowed  to  use  this  message.  The verified sender of a
  767. X      message is the Sender  line,    or  if    no  Sender  line  is
  768. X      present, the From line.  The verified sender of the cancel
  769. X      message must be the same as  either  the  Sender  or    From
  770. X      field  of  the original message.  A verified sender in the
  771. X      cancel message is allowed to match an unverified  From  in
  772. X      the original message.
  773. X
  774. X      3.2  Ihave/Sendme
  775.                Ihave/Sendme
  776.                Ihave/Sendme
  777.                Ihave/Sendme
  778. X
  779. X           ihave <message ID list> <remotesys>
  780. X           sendme <message ID list> <remotesys>
  781. X
  782. X      This message is part    of  the  ``ihave/sendme''  protocol,
  783. X      which  allows  one  site  (say ``A'') to tell another site
  784. X      (``B'') that a particular message has been received on  A.
  785. X      Suppose  that site A receives article ``ucbvax.1234'', and
  786. X      wishes to transmit the article to site  B.   A  sends  the
  787. X      control  message  ``ihave  ucbvax.1234  A''  to site B (by
  788. X
  789. X
  790. X
  791. X
  792. X
  793. X
  794. X
  795. X
  796. X
  797. X
  798. X
  799. X                    - 12 -
  800. X
  801. X
  802. X
  803. X      posting it to newsgroup ``to.B'').  B  responds  with  the
  804. X      control  message  ``sendme  ucbvax.1234  B'' (on newsgroup
  805. X      to.A) if it has not already received    the  article.    Upon
  806. X      receiving the Sendme message, A sends the article to B.
  807. X
  808. X      This protocol can be used to cut down on redundant traffic
  809. X      between  sites.  It is optional and should be used only if
  810. X      the particular situation makes it worthwhile.  Frequently,
  811. X      the  outcome    is  that,  since  most original messages are
  812. X      short, and since there is a high overhead to start sending
  813. X      a  new  message  with  UUCP,    it costs as much to send the
  814. X      Ihave as it would cost to send the article itself.
  815. X
  816. X      One possible solution to this overhead problem is to batch
  817. X      requests.   Several  message    ID's  may  be  announced  or
  818. X      requested in one message.  If no message ID's  are  listed
  819. X      in  the control message, the body of the message should be
  820. X      scanned for message ID's, one per line.
  821. X
  822. X      3.3  Newgroup
  823.                Newgroup
  824.                Newgroup
  825.                Newgroup
  826. X
  827. X           newgroup <groupname>
  828. X
  829. X      This control message creates a new newsgroup with the name
  830. X      given.  Since no articles may be posted or forwarded until
  831. X      a newsgroup is created, this message is required before  a
  832. X      newsgroup  can  be  used.   The  body  of  the  message is
  833. X      expected to be a short paragraph describing  the  intended
  834. X      use of the newsgroup.
  835. X
  836. X      3.4  Rmgroup
  837.                Rmgroup
  838.                Rmgroup
  839.                Rmgroup
  840. X
  841. X           rmgroup <groupname>
  842. X
  843. X      This message removes a  newsgroup  with  the    given  name.
  844. X      Since  the  newsgroup  is  removed  from every site on the
  845. X      network, this  command  should  be  used  carefully  by  a
  846. X      responsible administrator.
  847. X
  848. X      3.5  Sendsys
  849.                Sendsys
  850.                Sendsys
  851.                Sendsys
  852. X
  853. X           sendsys (no arguments)
  854. X
  855. X      The  ``sys''  file,  listing  all  neighbors   and   which
  856. X      newsgroups  are  sent  to each neighbor, will be mailed to
  857. X      the author of the control message (Reply-to,  if  present,
  858. X      otherwise  From).   This  information is considered public
  859. X      information, and it is  a  requirement  of  membership  in
  860. X      USENET  that    this  information  be  provided  on request,
  861. X      either automatically in response to this control  message,
  862. X      or  manually,  by mailing the requested information to the
  863. X
  864. X
  865. X
  866. X
  867. X
  868. X
  869. X
  870. X
  871. X
  872. X
  873. X
  874. X                    - 13 -
  875. X
  876. X
  877. X
  878. X      author of the message.  This information is used  to    keep
  879. X      the  map  of    USENET    up  to    date, and to determine where
  880. X      netnews is sent.
  881. X
  882. X      The format of the file mailed back to the author should be
  883. X      the same as that of the ``sys'' file.  This format has one
  884. X      line per neighboring site (plus one  line  for  the  local
  885. X      site),  containing four colon separated fields.  The first
  886. X      field has the site name of the neighbor, the second  field
  887. X      has  a newsgroup pattern describing the newsgroups sent to
  888. X      the neighbor.  The third and fourth fields are not defined
  889. X      by this standard.  A sample response:
  890. X
  891. X           From cbosgd!mark  Sun Mar 27 20:39:37 1983
  892. X           Subject: response to your sendsys request
  893. X           To: mark@cbosgd.UUCP
  894. X
  895. X           Responding-System: cbosgd.UUCP
  896. X           cbosgd:osg,cb,btl,bell,net,fa,to,test
  897. X           ucbvax:net,fa,to.ucbvax:L:
  898. X           cbosg:net,fa,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
  899. X           cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
  900. X           sescent:net,fa,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
  901. X           npois:net,fa,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
  902. X           mhuxi:net,fa,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi
  903. X
  904. X      3.6  Senduuname
  905.                Senduuname
  906.                Senduuname
  907.                Senduuname
  908. X
  909. X           senduuname      (no arguments)
  910. X
  911. X      The ``uuname'' program is run, and the output is mailed to
  912. X      the  author  of the control message (Reply-to, if present,
  913. X      otherwise From).  This program lists all uucp neighbors of
  914. X      the  local site.  This information is used to make maps of
  915. X      the UUCP network.  The sys file is not  the  same  as  the
  916.                                              ___
  917. X      UUCP     L.sys     file.     The  L.sys  file  should  never  be
  918.                                                            _____
  919. X      transmitted to another party without the  consent  of  the
  920. X      sites whose passwords are listed therein.
  921. X
  922. X      It is optional for a site  to  provide  this    information.
  923. X      Some    reply  should  be  made to the author of the control
  924. X      message, so that a transmission error won't be blamed.  It
  925. X      is  also  permissible for a site to run the uuname program
  926. X      (or in some other way determine the  uucp  neighbors)  and
  927. X      edit    the output, either automatically or manually, before
  928. X      mailing the reply back to the  author.   The    file  should
  929. X      contain  one    site  per line, beginning with the uucp site
  930. X      name.  Additional information may be    included,  separated
  931. X      from the site name by a blank or tab.  The phone number or
  932. X      password for the site should NOT be included, as the reply
  933. X      is  considered  to  be  in the public domain.  (The uuname
  934. X
  935. X
  936. X
  937. X
  938. X
  939. X
  940. X
  941. X
  942. X
  943. X
  944. X
  945. X                    - 14 -
  946. X
  947. X
  948. X
  949. X      program will send only the site name and  not  the  entire
  950. X      contents  of    the  L.sys  file,  thus,  phone  numbers and
  951. X      passwords are not transmitted.)
  952. X
  953. X      The purpose of this message is to  generate  and  maintain
  954. X      UUCP mail routing maps.  Thus, connections over which mail
  955. X      can be sent using the site!user syntax should be included,
  956. X      regardless  of whether the link is actually a UUCP link at
  957. X      the physical level.  If a mail router should    use  it,  it
  958. X      should   be  included.   Since  all  information  sent  in
  959. X      response to this message is optional, sites  are  free  to
  960. X      edit    the  list,  deleting secret or private links they do
  961. X      not wish to publicise.
  962. X
  963. X      3.7  Version
  964.                Version
  965.                Version
  966.                Version
  967. X
  968. X           version (no arguments)
  969. X
  970. X      The name and version of the software running on the  local
  971. X      system  is  to be mailed back to the author of the article
  972. X      (Reply-to if present, otherwise From).
  973. X
  974. X
  975. X      4.  Transmission Methods
  976.               Transmission Methods
  977.               Transmission Methods
  978.               Transmission Methods
  979. X
  980. X      USENET is not a physical network,  but  rather  a  logical
  981. X      network  resting  on    top  of  several  existing  physical
  982. X      networks.  These networks include, but are not limited to,
  983. X      UUCP,  the ARPANET, an Ethernet, the BLICN network, an NSC
  984. X      Hyperchannel, and a Berknet.    What is  important  is    that
  985. X      two  neighboring systems on USENET have some method to get
  986. X      a new article, in the format listed here, from one  system
  987. X      to  the other, and once on the receiving system, processed
  988. X      by the netnews software on that system.  (On UNIX systems,
  989. X      this    usually  means    the ``rnews'' program being run with
  990. X      the article on the standard input.)
  991. X
  992. X      It is not  a    requirement  that  USENET  sites  have    mail
  993. X      systems  capable  of    understanding the ARPA Internet mail
  994. X      syntax, but  it  is  strongly  recommended.    Since  From,
  995. X      Reply-To,  and  Sender  lines  use  the  Internet  syntax,
  996. X      replies  will  be  difficult    or  impossible    without   an
  997. X      internet  mailer.   A  site without an internet mailer can
  998. X      attempt to use the Path header line for replies, but    this
  999. X      field  is not guaranteed to be a working path for replies.
  1000. X      In any event,  any  site  generating    or  forwarding    news
  1001. X      messages must have an internet address that allows them to
  1002. X      receive mail from sites with internet  mailers,  and    they
  1003. X      must include their internet address on their From line.
  1004. X
  1005. X
  1006. X
  1007. X
  1008. X
  1009. X
  1010. X
  1011. X
  1012. X
  1013. X
  1014. X
  1015. X
  1016. X
  1017. X                    - 15 -
  1018. X
  1019. X
  1020. X
  1021. X      4.1  Remote Execution
  1022.                Remote Execution
  1023.                Remote Execution
  1024.                Remote Execution
  1025. X
  1026. X      Some networks permit direct remote command execution.   On
  1027. X      these  networks,  news  may  be  forwarded by spooling the
  1028. X      rnews command with the article on the standard input.  For
  1029. X      example,  if    the remote system is called ``remote'', news
  1030. X      would be sent over a UUCP link with the  command  ``uux  -
  1031. X      remote!rnews'',  and on a Berknet, ``net -mremote rnews''.
  1032. X      It is important that the article be sent  via  a  reliable
  1033. X      mechansim, normally involving the possibility of spooling,
  1034. X      rather than direct real-time remote  execution.   This  is
  1035. X      because,  if the remote system is down, a direct execution
  1036. X      command  will  fail,    and  the  article  will   never   be
  1037. X      delivered.   If the article is spooled, it will eventually
  1038. X      be delivered when both systems are up.
  1039. X
  1040. X      4.2  Transfer by Mail
  1041.                Transfer by Mail
  1042.                Transfer by Mail
  1043.                Transfer by Mail
  1044. X
  1045. X      On some systems, direct remote spooled  execution  is  not
  1046. X      possible.   However, most systems support electronic mail,
  1047. X      and a news article can be sent as mail.  One    approach  is
  1048. X      to  send  a  mail  message  which is identical to the news
  1049. X      message: the mail headers are the news  headers,  and  the
  1050. X      mail    body  is the news body.  By convention, this mail is
  1051. X      sent to the user ``newsmail'' on the remote machine.
  1052. X
  1053. X      One problem with  this  method  is  that  it    may  not  be
  1054. X      possible to convince the mail system that the From line of
  1055. X      the message is valid, since the mail message was generated
  1056. X      by  a program on a system different from the source of the
  1057. X      news article.  Another  problem  is  that  error  messages
  1058. X      caused  by  the  mail  transmission  would  be sent to the
  1059. X      originator of the news article, who has  no  control    over
  1060. X      news    transmission  between two cooperating hosts and does
  1061. X      not know who    to  contact.   Transmission  error  messages
  1062. X      should  be directed to a responsible contact person on the
  1063. X      sending machine.
  1064. X
  1065. X      A solution to this problem  is  to  encapsulate  the    news
  1066. X      article  into a mail message, such that the entire article
  1067. X      (headers and body) are  part  of  the  body  of  the  mail
  1068. X      message.  The convention here is that such mail is sent to
  1069. X      user ``rnews'' on the remote system.  A mail message  body
  1070. X      is  generated  by prepending the letter ``N'' to each line
  1071. X      of the news article,    and  then  attaching  whatever    mail
  1072. X      headers  are convenient to generate.    The N's are attached
  1073. X      to prevent any special lines    in  the  news  article    from
  1074. X      interfering  with  mail  transmission,  and to prevent any
  1075. X      extra lines inserted by the mailer (headers, blank  lines,
  1076. X      etc.)  from  becoming part of the news article.  A program
  1077. X      on the  receiving  machine  receives    mail  to  ``rnews'',
  1078. X
  1079. X
  1080. X
  1081. X
  1082. X
  1083. X
  1084. X
  1085. X
  1086. X
  1087. X
  1088. X
  1089. X                    - 16 -
  1090. X
  1091. X
  1092. X
  1093. X      extracting  the  article itself and invoking the ``rnews''
  1094. X      program.  An example in this format might look like this:
  1095. X
  1096. X           Date: Monday, 3-Jan-83 08:33:47 MST
  1097. X           From: news@cbosgd.UUCP
  1098. X           Subject: network news article
  1099. X           To: rnews@npois.UUCP
  1100. X
  1101. X           NRelay-Version: B 2.10  2/13/83 cbosgd.UUCP
  1102. X           NPosting-Version: B 2.9 6/21/82 sask.UUCP
  1103. X           NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
  1104. X           NFrom: derek@sask.UUCP (Derek Andrew)
  1105. X           NNewsgroups: net.test
  1106. X           NSubject: necessary test
  1107. X           NMessage-ID: <176@sask.UUCP>
  1108. X           NDate: Monday, 3-Jan-83 00:59:15 MST
  1109. X           N
  1110. X           NThis really is a test.    If anyone out there more than 6
  1111. X           Nhops away would kindly confirm this note I would
  1112. X           Nappreciate it.    We suspect that our news postings
  1113. X           Nare not getting out into the world.
  1114. X           N
  1115. X
  1116. X
  1117. X      Using mail solves the spooling problem,  since  mail    must
  1118. X      always  be  spooled  if  the    destination  host  is  down.
  1119. X      However, it adds more overhead to the transmission process
  1120. X      (to  encapsulate  and  extract  the  article) and makes it
  1121. X      harder for software to give different priorities  to    news
  1122. X      and mail.
  1123. X
  1124. X      4.3  Batching
  1125.                Batching
  1126.                Batching
  1127.                Batching
  1128. X
  1129. X      Since news articles are usually short, and since  a  large
  1130. X      number  of  messages are often sent between two sites in a
  1131. X      day, it may make sense to batch  news  articles.   Several
  1132. X      articles  can  be  combined  into one large article, using
  1133. X      conventions agreed upon in advance by the two sites.     One
  1134. X      such    batching  scheme is described here; its use is still
  1135. X      considered experimental.
  1136. X
  1137. X      News articles are combined into a script, separated  by  a
  1138. X      header of the form:
  1139. X
  1140. X           ##! rnews 1234
  1141. X
  1142. X      where 1234 is the length, in bytes, of the article.    Each
  1143. X      such    line  is followed by an article containing the given
  1144. X      number of bytes.  (The newline at the end of each line  of
  1145. X      the  article    is counted as one byte, for purposes of this
  1146. X      count, even if it is stored as CRLF.) For example, a batch
  1147. X
  1148. X
  1149. X
  1150. X
  1151. X
  1152. X
  1153. X
  1154. X
  1155. X
  1156. X
  1157. X
  1158. X                    - 17 -
  1159. X
  1160. X
  1161. X
  1162. X      of articles might look like this:
  1163. X
  1164. X        #! rnews 374
  1165. X        Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
  1166. X        Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
  1167. X        Path: cbosgd!mhuxj!mhuxt!eagle!jerry
  1168. X        From: jerry@eagle.uucp (Jerry Schwarz)
  1169. X        Newsgroups: net.general
  1170. X        Subject: Usenet Etiquette -- Please Read
  1171. X        Message-ID: <642@eagle.UUCP>
  1172. X        Date: Friday, 19-Nov-82 16:14:55 EST
  1173. X
  1174. X        Here is an important message about USENET Etiquette.
  1175. X        #! rnews 378
  1176. X        Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
  1177. X        Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
  1178. X        Path: cbosgd!mhuxj!mhuxt!eagle!jerry
  1179. X        From: jerry@eagle.uucp (Jerry Schwarz)
  1180. X        Newsgroups: net.followup
  1181. X        Subject: Notes on Etiquette article
  1182. X        Message-ID: <643@eagle.UUCP>
  1183. X        Date: Friday, 19-Nov-82 17:24:12 EST
  1184. X
  1185. X        There was something I forgot to mention in the last message.
  1186. X
  1187. X      Batched news is recognized because the first character  in
  1188. X      the  message    is ``#''.  The message is then passed to the
  1189. X      unbatcher for interpretation.
  1190. X
  1191. X
  1192. X      5.  The News Propagation Algorithm
  1193.               The News Propagation Algorithm
  1194.               The News Propagation Algorithm
  1195.               The News Propagation Algorithm
  1196. X
  1197. X      This section describes the overall scheme  of  USENET  and
  1198. X      the algorithm followed by sites in propagating news to the
  1199. X      entire  network.   Since  all  sites     are   affected   by
  1200. X      incorrectly  formatted articles and by propagation errors,
  1201. X      it is important for the method to be standardized.
  1202. X
  1203. X      USENET is a directed graph.  Each node in the graph  is  a
  1204. X      host    computer,  each  arc  in the graph is a transmission
  1205. X      path from one host to another host.  Each arc is  labelled
  1206. X      with    a  newsgroup  pattern,    specifying  which  newsgroup
  1207. X      classes are forwarded along  that  link.   Most  arcs  are
  1208. X      bidirectional,  that    is,  if  site  A  sends  a  class of
  1209. X      newsgroups to site B, then site B usually sends  the    same
  1210. X      class  of  newsgroups to site A.  This bidirectionality is
  1211. X      not, however, required.
  1212. X
  1213. X      USENET is made up of many subnetworks.  Each subnet has  a
  1214. X      name,  such  as  ``net''  or  ``btl''.  The special subnet
  1215. X      ``net'' is defined to be USENET, although the union of all
  1216. X
  1217. X
  1218. X
  1219. X
  1220. X
  1221. X
  1222. X
  1223. X
  1224. X
  1225. X
  1226. X
  1227. X                    - 18 -
  1228. X
  1229. X
  1230. X
  1231. X      subnets may be a superset of USENET (because of sites that
  1232. X      get local newsgroup classes but do not get net.all).    Each
  1233. X      subnet  is  a connected graph, that is, a path exists from
  1234. X      every  node  to  every  other  node  in  the    subnet.   In
  1235. X      addition,  the  entire graph is (theoretically) connected.
  1236. X      (In practice, some political  considerations  have  caused
  1237. X      some sites to be unable to post articles reaching the rest
  1238. X      of the network.)
  1239. X
  1240. X      An  article  is  posted  on  one  machine  to  a  list  of
  1241. X      newsgroups.     That    machine  accepts  it  locally,    then
  1242. X      forwards it to all its neighbors that are interested in at
  1243. X      least one of the newsgroups of the message.  (Site A deems
  1244. X      site    B  to  be  ``interested''  in  a  newsgroup  if  the
  1245. X      newsgroup  matches  the  pattern  on    the arc from A to B.
  1246. X      This pattern is stored in a file on the  A  machine.)  The
  1247. X      sites  receiving  the  incoming article examine it to make
  1248. X      sure they really want the article, accept it locally,  and
  1249. X      then    in  turn forward the article to all their interested
  1250.                                                     _____
  1251. X      neighbors.   This  process  continues  until    the   entire
  1252. X      network has seen the article.
  1253. X
  1254. X      An important part of the algorithm is  the  prevention  of
  1255. X      loops.   The    above  process would cause a message to loop
  1256. X      along a cycle forever.  In particular, when site  A  sends
  1257. X      an  article to site B, site B will send it back to site A,
  1258. X      which will send it to site B, and so on.  One solution  to
  1259. X      this    is  the history mechanism.  Each site keeps track of
  1260. X      all articles    it  has  seen  (by  their  message  ID)  and
  1261. X      whenever an article comes in that it has already seen, the
  1262. X      incoming article is discarded immediately.  This  solution
  1263. X      is   sufficient   to     prevent   loops,   but   additional
  1264. X      optimizations can be made to    avoid  sending    articles  to
  1265. X      sites that will simply throw them away.
  1266. X
  1267. X      One optimization is that an article should never  be    sent
  1268. X      to  a machine listed in the Path line of the header.    When
  1269. X      a machine name is in the Path line, the message  is  known
  1270. X      to  have passed through the machine.    Another optimization
  1271. X      is that, if the article originated on site A, then site  A
  1272. X      has    already  seen  the  article.   (Origination  can  be
  1273. X      determined by the Posting-Version line.)
  1274. X
  1275. X      Thus, if an article is posted to  newsgroup  ``net.misc'',
  1276. X      it  will match the pattern ``net.all'' (where ``all'' is a
  1277. X      metasymbol that matches any string), and will be forwarded
  1278. X      to  all  sites that subscribe to net.all (as determined by
  1279. X      what their neighbors send them).  These sites make up  the
  1280. X      ``net''  subnetwork.  An article posted to ``btl.general''
  1281. X      will reach all sites receiving ``btl.all'', but  will  not
  1282. X      reach  sites    that do not get ``btl.all''.  In effect, the
  1283. X
  1284. X
  1285. X
  1286. X
  1287. X
  1288. X
  1289. X
  1290. X
  1291. X
  1292. X
  1293. X
  1294. X                    - 19 -
  1295. X
  1296. X
  1297. X
  1298. X      articles  reaches  the  ``btl''  subnetwork.   An  article
  1299. X      posted  to newsgroups ``net.micro,btl.general'' will reach
  1300. X      all sites subscribing to either of the two classes.
  1301. X
  1302. X
  1303. X
  1304. X
  1305. X
  1306. X
  1307. X
  1308. X
  1309. X
  1310. X
  1311. X
  1312. X
  1313. X
  1314. X
  1315. X
  1316. X
  1317. X
  1318. X
  1319. X
  1320. X
  1321. X
  1322. X
  1323. X
  1324. X
  1325. X
  1326. X
  1327. X
  1328. X
  1329. X
  1330. X
  1331. X
  1332. X
  1333. X
  1334. X
  1335. X
  1336. X
  1337. X
  1338. X
  1339. X
  1340. X
  1341. X
  1342. X
  1343. X
  1344. X
  1345. X
  1346. X
  1347. X
  1348. X
  1349. X
  1350. X
  1351. X
  1352. X
  1353. X
  1354. X
  1355. X
  1356. X
  1357. X
  1358. X
  1359. X============
  1360. X
  1361. XFrom schein  Thu Jun  9 14:36:35 1988 remote from cbmvax
  1362. XReceived: by cbmvax.UUCP (1.2/UUCP-Project/Commodore 12/21/87))
  1363. X    id AA14116; Thu, 9 Jun 88 14:36:35 edt
  1364. XDate: Thu, 9 Jun 88 14:36:35 edt
  1365. XFrom: cbmvax!schein (Dan Schein CATS)
  1366. XMessage-Id: <8806091836.AA14116@cbmvax.UUCP>
  1367. XTo: heimat!sysop
  1368. XSubject: How to UseNet
  1369. X
  1370. X
  1371. X                How to Use USENET Effectively
  1372. X
  1373. X
  1374. X                     Matt Bishop
  1375. X          Research Institute for Advanced Computer Science
  1376. X                   Mail Stop 230-5
  1377. X                  NASA Ames Research Center
  1378. X
  1379. X                  Moffett Field, CA  94035
  1380. X
  1381. X
  1382. X
  1383. X      1.  Introduction
  1384. X
  1385. X           USENET  is  a  worldwide  bulletin  board  system  in  which
  1386. X      thousands of computers pass articles back and forth.    Of necessi-
  1387. X      ty, customs have sprung  up  enabling  very  diverse    people    and
  1388. X      groups  to  communicate  peaceably  and effectively using USENET.
  1389. X      These customs are for the most part written,    but  are  scattered
  1390. X      over    several  documents  that  can  be difficult to find; in any
  1391. X      case, even if a new user can find  all  the  documents,  he  most
  1392. X      likely  will    have  neither  the time nor the inclination to read
  1393. X      them all.  This document is intended to collect all these conven-
  1394. X      tions  into  one  place,  thereby making it easy for new users to
  1395. X      learn about the world of USENET.  (Old-timers, too, will  benefit
  1396. X      from reading this.)
  1397. X
  1398. X           You should read this document and understand  it  thoroughly
  1399. X      before  you even think about posting anything.  If you have ques-
  1400. X      tions, please ask your USENET administrator (who can  usually  be
  1401. X      reached by sending mail to usenet) or a more knowledgeable USENET
  1402. X      user.  Believe me, you will save yourself a lot of grief.
  1403. X
  1404. X           The mechanics of posting an article to USENET are  explained
  1405. END_OF_FILE
  1406. if test 48305 -ne `wc -c <'man/Standards.aa'`; then
  1407.     echo shar: \"'man/Standards.aa'\" unpacked with wrong size!
  1408. fi
  1409. # end of 'man/Standards.aa'
  1410. fi
  1411. echo shar: End of archive 15 \(of 16\).
  1412. cp /dev/null ark15isdone
  1413. MISSING=""
  1414. for I in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ; do
  1415.     if test ! -f ark${I}isdone ; then
  1416.     MISSING="${MISSING} ${I}"
  1417.     fi
  1418. done
  1419. if test "${MISSING}" = "" ; then
  1420.     echo You have unpacked all 16 archives.
  1421.     rm -f ark[1-9]isdone ark[1-9][0-9]isdone
  1422. else
  1423.     echo You still need to unpack the following archives:
  1424.     echo "        " ${MISSING}
  1425. fi
  1426. ##  End of shell archive.
  1427. exit 0
  1428. -- 
  1429. Submissions to comp.sources.amiga and comp.binaries.amiga should be sent to:
  1430.     amiga@cs.odu.edu    
  1431. or    amiga@xanth.cs.odu.edu    ( obsolescent mailers may need this address )
  1432. or    ...!uunet!xanth!amiga    ( very obsolescent mailers need this address )
  1433.  
  1434. Comments, questions, and suggestions should be addressed to ``amiga-request''
  1435. (please only use ``amiga'' for actual submissions) at the above addresses.
  1436.